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Abstract — Today, the technology for video streaming over 
the Internet is converging towards a paradigm named HTTP- 
based adaptive streaming (HAS), which brings two new features. 
First, by using HTTP/TCP, it leverages network-friendly TCP 
to achieve both flrewall/NAT traversal and bandwidth sharing. 
Second, by pre-encoding and storing the video in a number of 
discrete rate levels, it introduces video bitrate adaptivity in a 
scalable way so that the video encoding is excluded from the 
closed-loop adaptation. A conventional wisdom is that the TCP 
throughput observed by an HAS client indicates the available 
network bandwidth, and thus can be used as a reliable reference 
for video bitrate selection. 

We argue that this is no longer true when HAS becomes 
a substantial fraction of the total traffic. We show that when 
multiple HAS clients compete at a network bottleneck, the 
presence of competing clients and the discrete nature of the 
video bitrates together result in difficulty for a client to correctly 
perceive its fair-share bandwidth. Through analysis and test bed 
experiments, we demonstrate that this fundamental limitation 
leads to, for example, video bitrate oscillation that negatively 
impacts the video viewing experience. We therefore argue that 
it is necessary to design at the application layer using a "probe- 
and-adapt" principle for HAS video bitrate adaptation, which 
is akin to, but also independent of the transport-layer TCP 
congestion control. We present PANDA - a client-side rate 
adaptation algorithm for HAS - as practical embodiment of 
this principle. Our test bed results show that compared to 
conventional algorithms, PANDA is able to reduce the instability 
of video bitrate selection by over 75% without increasing the 
risk of buffer underrun. 

I. Introduction 

Over the past few years, we have witnessed a major tech- 
nology convergence for Internet video streaming towards a 
new paradigm named HTTP-based adaptive streaming (HAS). 
Since its inception in 2007 by Move Networks [1|, HAS has 
been quickly adopted by major vendors and service providers. 
Today, HAS is employed for over-the-top video delivery by 
many major media content providers. A recent report by Cisco 
jTil predicts that video will constitute more than 90% of the 
total Internet traffic by 2014. Therefore, HAS may become a 
predominant form of Internet traffic in just a few years. 

In contrast to conventional RTP/UDP-based video stream- 
ing, HAS uses HTTP/TCP - the protocol stack traditionally 
used for Web traffic. In HAS, a video stream is chopped 
into short segments of a few seconds each. Each segment is 
pre-encoded and stored at a server in a number of versions, 
each with a distinct video bitrate, resolution and/or quality. 
After obtaining a manifest file with necessary information, a 
client downloads the segments sequentially using plain HTTP 
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Fig. I. Oscillation of video bitrate when 36 Microsoft Smooth clients 
compete at a 100-Mbps link. For more detailed experimental setup, refer to 

GETs, estimates the network conditions, and selects the video 
bitrate of the next segment on-the-fly. A conventional wisdom 
is that since the bandwidth sharing of HAS is dictated by 
TCP, the problem of video bitrate selection can be resolved 
straightforwardly. A simple rule of thumb is to approximately 
match the video bitrate to the observed TCP throughput. 

A. Emerging Issues 

A major trend in HAS use cases is its large-scale de- 
ployment in managed networks by service providers, which 
typically leads to aggregating multiple HAS streams in the 
aggregation/core network. For example, an important scenario 
is that within a single household or a neighborhood, several 
HAS flows belonging to one DOCSI!^ bonding group compete 
for bandwidth. In the unmanaged wide-area Internet, as HAS 
is growing to become a substantial fraction of the total traffic, 
it will also become more and more common to have multiple 
HAS streams compete for available bandwidth at any network 
bottlenecks. 

While a simple rate adaptation algorithm might work fairly 
well for the case where a single HAS stream operates alone 
or shares bandwidth with non-HAS traffic, recent studies 
[131, [3 1 have reported undesirable behaviors when multiple 
HAS streams compete for bandwidth at a bottleneck link. For 
example, while studies have suggested that significant video 
quality variation over time is undesirable for a viewer's quality 
of experience [181 , in [13] the authors reported unstable video 

'Data over cable service interface specification. 



bitrate selection and unfair bandwidth sharing among three 
Microsoft Smooth cHents sharing a 3-Mbps link. In our own 
test bed experiments (see Figure [T), we observed significant 
and regular video bitrate oscillation when multiple Microsoft 
Smooth clients share a bottleneck link. We also found that 
oscillation behavior persists under a wide range of parameter 
settings, including the number of players, link bandwidth, start 
time of clients, heterogeneous RTTs, random early detection 
(RED) queueing parameters, the use of weight fair queueing 
(WFQ), the presence of moderate web-like cross traffic, etc. 

Our study shows that these HAS rate oscillation and insta- 
bility behaviors are not incidental - they are simply symptoms 
of a much more fundamental limitation of the conventional 
HAS rate adaptation algorithms, in which the TCP down- 
loading throughput observed by a client is directly equated 
to its fair share of the network bandwidth. This fundamental 
problem would also impact a HAS client's ability to avoid 
buffer underrun when the bandwidth suddenly drops. In brief, 
the problem derives from the discrete nature of HAS video 
bitrates. This makes it impossible to always match the video 
bitrate to the network bandwidth, resulting in undersubscrip- 
tion of the network bandwidth. Undersubscription is typically 
coupled with clients' on-off downloading patterns. The off- 
intervals then become a source of ambiguity for a client to 
correctly perceive its fair share of the network bandwidth, 
thus preventing the client from making accurate rate adaptation 
decision^. 

B. Overview of Solution 

To overcome this fundamental limitation, we envision a 
solution based on a "probe-and-adapt" principle. In this ap- 
proach, the TCP downloading throughput is taken as an 
input only when it is an accurate indicator of the fair-share 
bandwidth. This usually happens when the network is over- 
subscribed (or congested) and the off-intervals are absent. In 
the presence of off-intervals, the algorithm constantly proZ^ej^ 
the network bandwidth by incrementing its sending rate, and 
prepares to back off once it experiences congestion. This 
new mechanism shares the same spirit with TCP's congestion 
control, but it operates independently at the application layer 
and at a per-segment rather than a per-RTT time scale. We 
present PANDA (Probe AND Adapt) - a client-side rate 
adaptation algorithm - as a specific implementation of this 
principle. 

Probing constitutes fine-tuning the requested network data 
rate, with continuous variation over a range. By nature, the 
available video bitrates in HAS can only be discrete. A main 
challenge in our design is to create a continuous decision space 
out of the discrete video bitrate. To this end, we propose to 
fine-tune the intervals between consecutive segment download 

^In (3), Akhshabi et al. have reached similar conclusions. But they identify 
the off-intervals instead of the TCP throughput-based measurement as the 
root cause. Their sequel work attempts to tackle the problem from a veiy 
different angle using traffic shaping. 

^By probing, we mean small trial increment of data rate, instead of sending 
auxihary piggybacking traffic. 
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Fig. 2. Illustration of PANDA's fine-granular request intervals vs. a 
conventional algorithm's bimodal request intervals. 
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Probing additive increase bitrate 


K 


Probing convergence rate 


a 


Smoothing convergence rate 





Client buffer convergence rate 


A 


Quantization margin 


e 


Multiplicative safety margin 

Video segment duration (in video time) 


r 


B 


Client buffer duration (in video time) 




Minimum/maximum client buffer duration 


T 


Actual inter-request time 


f 


Target inter-request time 


f 


Segment download duration 


X 


Actual average data rate 


X 


Target average data rate (or bandwidth share) 


y 


Smoothed version of x 


X 


TCP throughput measured, x :— ^ 
Set of video bitrates TZ := {Ri, Rl} 


n 


r 


Video bitrate available from TZ 


s{-) 


Rate smoothing function 


Q(-) 


Video bitrate quantization function 



TABLE I 
Notations used in this paper 



requests such that the average data rate sent over the network 
is a continuous variable (see Figure |2] for an illustrative com- 
parison with the conventional scheme). Consequently, instead 
of directly tuning the video bitrate, we probe the bandwidth 
based on the average data rate, which in turn determines the 
selected video bitrate and the fine-granularity inter-request 
time. 

There are various benefits associated with the probe-and- 
adapt approach. First, it avoids the pitfall of inaccurate band- 
width estimation. Having a robust bandwidth measurement 
to begin with gives the subsequent operations improved dis- 
criminative power (for example, strong smoothing of the 
bandwidth measurement is no longer required, leading to 
better responsiveness). Second, with constant probing via 
incrementing the rate, the network bandwidth can be more 
efficiently utilized. Third, it ensures that the bandwidth sharing 
converges towards fair share (i.e., the same or adjacent video 
bitrate) among competing clients. Lastly, an innate feature of 
the probe-and-adapt approach is asymmetry of rate shifting - 
PANDA is equipped with conservative rate level upshift but 
more responsive downshift. Responsive downshift facilitates 
fast recovery from sudden bandwidth drops, and thus can 
effectively mitigate the danger of playout stalls caused by 
buffer underrun. 



C. Paper Organization 

In the rest of the paper, we first give a brief overview of 
the related work (§111). After formaHzing the problem (i jllll) . 
we first introduce a method to characterize the conventional 
rate adaptation algorithms (i llVI) . based on which we analyze 
the root cause of its problems {^^. We then introduce our 
probe-and-adapt approach ( Wil l to directly address the root 
cause, and present the PANDA rate adaptation algorithm as a 
concrete implementation of this idea. We provide comprehen- 
sive performance evaluations ( WIB . We conclude the paper 
with final remarks and discussion of future work ( Willi ). 

II. Related Work 

AIMD Principle: The design of the probing mechanism in 
PANDA shares similarity with Jacobson's additive-increase- 
multiplicative-decrease (AIMD) principle for TCP congestion 
control fTTl. Kelly's framework on network rate control [14] 
provides a theoretical justification for the AIMD principle, and 
proves its stability in the general network setup. 

HAS Measurement Studies: Various research efforts have 
focused on understanding the behavior of several commer- 
cially deployed HAS systems. One such example is 121, 
where the authors characterize and evaluate HTTP streaming 
players such as Microsoft Smooth Streaming, Netflix, and 
Adobe OSMF via experiments in controlled settings. The first 
measurement study to consider HAS streaming in the multi- 
client scenarios is [3J. The authors identify the root cause of 
the player's rate oscillation problem as the existence of on-off 
patterns in HAS traffic. In fT(F|, the authors measure behavior 
of commercial video streaming services, i.e., Hulu, Netflix, 
and Vudu, when competing with other long-Uved TCP flows. 
The results revealed that inaccurate estimations can trigger a 
feedback loop leading to undesirably low-quality video. 

Existing HAS Designs: To improve the performance of 
adaptive HTTP streaming, several rate adaptation algorithms 
|fT5l , |fT9l , ||20l , 1.171 , L16| have been proposed, which, in 
general, fit into the four-step model discussed in Section lTlI-Bj 
In lfT2l . a sophisticated Markov Decision Process (MDP) is 
employed to compute a set of optimal client strategies in order 
to maximize viewing quality. The MDP requires the knowl- 
edge of network conditions and video content statistics, which 
may not be readily available. Control-theoretical approaches, 
including use of a PID controller, are also considered by 
several works fSl, [T9l, ["201. A PID controller with appropriate 
parameter choice can improve streaming performance. Server- 
side mechanisms are also advocated by some works ||9], flU. 
Two designs have been considered to address the multi-client 
issues: in [4J, a rate-shaping approach aiming to eliminate the 
off-intervals, and in |13|, a client rate adaptation algorithm 
design implementing a combination of randomization, stateful 
rate selection and harmonic mean based averaging. 

III. Problem Model 

In this section, we formalize the problem by first describing 
a representative HAS server-client interaction process. We 
then outline a four-step model for an HAS rate adaptation 
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Fig. 3. The HAS segment downloading process. 

algorithm. This will allow us to compare the proposed PANDA 
algorithm with its conventional counterpart. Table |I] lists the 
main notations used in this paper 

A. Process of HAS Server-Client Interaction 

Consider that a video stream is chopped into segments of t 
seconds each. Each segment has been pre-encoded at L video 
bitrates, all stored at a server Denote by TZ := {Ri, Rl} 
the set of available video bitrates, with Q < Rg < for 
£ <m. 

For each client, the streaming process is divided into se- 
quential segment downloading steps n — 1,2, .... The process 
we consider here generalizes the process used by conventional 
HAS clients by further incorporating variable durations be- 
tween consecutive segment requests. Refer to Figure |3] At 
the beginning of each download step n, a rate adaptation 
algorithm: 

• Selects the video bitrate of the next segment to be 
downloaded, r[n] £ TZ; 

• Specifies how much time to give for the current down- 
load, until the next download request (i.e., the inter- 
request time), T[n]. 

The client then initiates an HTTP GET request to the server 
for the segment of sequence number n and video bitrate 
r[n], and the downloading starts immediately. Let T[n] be 
the download duration - the time required to complete the 
download. Assuming that no pipelining of downloading is 
involved, the next download step starts after time 



T[n\ = max(T[n], T[n]), 



(1) 



where T[n] is the actual inter-request time. That is, if the 
download duration T[n] is shorter than the target delay T[n], 
the client waits time T[n] — T[n] (i.e., the off-interval) before 
starting the next downloading step (Scenario A); otherwise, 
the client starts the next download step immediately after the 
current download is completed (Scenario B). 

Typically, a rate adaptation algorithm also measures its TCP 
throughput X during the segment downloading, via: 



x\n\ 



r[n\ ■ T 



The downloaded segments are stored in the client buffer 
After playout starts, the buffer is consumed by the video 
player at a natural rate of one video second per real second on 
average. Let B[n] be the buffer duration (measured in video 
time) at the end of step n. Then the buffer dynamics can be 
characterized by: 



B[n] = max (0, B[n - 1] + t - T[n]) . 



(2) 



Algorithm 1 Conventional 

At the beginning of each downloading step n: 

1) Estimate the bandwidth share x[n] by equating it to the measured TCP 
throughput: 

x[n] = x[n — 1]. (3) 

2) Smooth out x[n] to produce filtered version y[n] by 

y[n] = S{{x[m] : m < n}). (4) 

3) Quantize y[n] to the discrete video bitrate r[n] G 7^ by 

r[n] = Qiy[n];...). (5) 

4) Schedule the next download request depending on the buffer fullness: 

T, otherwise. 



B. Four-Step Model 

We present a four-step model for an HAS rate adaptation 
algorithm, generic enough to encompass both the conventional 
algorithms (e.g., 1151, 119J, |]|20J, L17|, |16|) and the proposed 
PANDA algorithm. In this model, a rate adaptation algorithm 
proceeds in the following four steps. 

• Estimating. The algorithm starts by estimating the net- 
work bandwidth x[n] that can legitimately be used. 

• Smoothing. x[n] is then noise-filtered to yield the 
smoothed version y[n], with the aim of removing outliers. 

• Quantizing. The continuous y[n] is then mapped to the 
discrete video bitrate r[n] E TZ, possibly with the help of 
side information such as client buffer size, etc. 

• Scheduling. The algorithm selects the target interval until 
the next download request, T[n]. 

IV. Conventional Approach 

Using the four-step model above, in this section we intro- 
duce a scheme to characterize a conventional rate adaptation 
algorithm, which will serve as a benchmark. 

To the best of our knowledge, almost all of today's commer- 
cial HAS player^ implement the measuring and scheduling 
parts of the rate adaptation algorithm in a similar way, though 
they may differ in their implementation of the smoothing 
and quantizing parts of the algorithm. Our claim is based 
on a number of experimental studies of commercial HAS 
players ID, IfTOl . |fT3l . The scheme described in Algorithm 
[T] characterizes their essential ideas. 

First, the algorithm equates the currently available band- 
width share x[n] to the past TCP throughput 5 [n — 1] observed 
during the on-interval T[n — 1]. As the bandwidth is inferred 
reactively based on the previous downloads, we refer to this 
as reactive bandwidth estimation. 

The algorithm then obtains a filtered version y[n] using a 
smoothing function S{-) that takes as input the measurement 
history {^[to] : m < n}, as described in (|4]i. Various filtering 
methods are possible, such as sliding-window moving average, 

*In this paper, the terms "HAS player" and "HAS client" are used 
interchangeably. 



exponential weighted moving average (EWMA) or harmonic 
mean lfT3l . 

The next step maps the continuous y[n] to a discrete video 
bitrate r[n] £ TZ using a quantization function Q{-).Ir general, 
Q{-) can also incorporate side information, including the past 
fetched bitrates {r[ni] : m < n} and the buffer history {^[to] : 
m < n}. 

Lastly, the algorithm determines the target inter-request time 
T[n]. In (|6l), T[n] is a mechanical function of the buffer 
duration B[n — 1]. If B[n — 1] is less than a pre-defined 
maximum buffer Smax, T[n] is set to 0, and by ([T]), the next 
segment downloading starts right after the current download 
is finished; otherwise, the inter-request time is set to the video 
segment duration t, to stop the buffer from further growing. 
This creates two distinct modes of segment downloading - 
the buffer growing mode and the steady-state mode, as shown 
in Figure |2jb). We refer to this as the bimodal download 
scheduling. 

V. Analysis of the Conventional Approach 

In this section, we take a deep dive into the conventional 
rate adaptation algorithms and study their limitations. 

A. Bandwidth Cliff Effect 

As we have seen in the previous section, conventional 
rate adaptation algorithms use reactive bandwidth estimation 
Q that equates the estimated bandwidth share to the TCP 
throughput observed during the on-intervals. In the presence 
of competing HAS clients, however, the TCP throughput does 
not always faithfully represent the fair-share bandwidth. In this 
section, we extend the analysis first presented in Q. 

First, we illustrate with simple examples. Figure 2] (a) - (e) 
show the various scenarios of how a link can be shared by two 
HAS clients in steady-state mode. We consider three different 
scenarios: perfect link subscription, link oversubscription and 
link undersubscription. We assume ideal TCP behavior, i.e., 
perfectly equal sharing of the available bandwidth when the 
transfers overlap. 

Perfect Subscription: In perfect link subscription, the total 
amount of traffic requested by the two clients perfectly fills the 
link, (a), (b) and (c) illustrate three different modes of band- 
width sharing, depending on the starting time of downloads 
relative to each other Essentially, under perfect subscription, 
there are unlimited number of bandwidth sharing modes. 

Oversubscription: In (d), the two clients start with round- 
robin mode and perfect subscription. Starting from the second 
round of downloading, the bandwidth is reduced and the link 
becomes oversubscribed, i.e., each client requests segments 
larger than its current fair-share portion of the bandwidth. 
This will result in unfinished downloads at the end of each 
downloading round. Then, the unfinished segment will start 
overlapping with segments of the next round. This repeats and 
the downloading will become more and more overlapped, until 
all the clients enter the fully overlapped mode. 

Undersubscription: In (e), initially the bandwidth sharing 
is in fully overlapped mode, and the link is oversubscribed. 
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Fig. 4. Illustration of various bandwidth sharing scenarios. In (a), (b) and (c), the link is perfectly subscribed. In (d), the bandwidth sharing starts with 
round-robin mode but then link becomes oversubscribed. In (e), the bandwidth sharing starts with fully overlapped mode when the link is oversubscribed. 
Starting from the second round, the link becomes undersubscribed. In (f), a single client is downloading, and the downloading on-off pattern exactly matches 
that of the blue segments in (a). 



Starting from the second round, the bandwidth increases and 
the Unk becomes undersubscribed. Then the clients start filling 
up each other's off-intervals, until a transmission gap emerges. 
The bandwidth sharing will eventually converge to a mode 
which is determined by the download start times. 

In any case, the measured TCP throughput faithfully rep- 
resents the fair-share bandwidth only when the bandwidth 
sharing is in the fully overlapped mode; in all other cases the 
TCP throughput overestimates the fair-share bandwidth. Thus, 
most of the time, the bandwidth estimate is accurate when 
the link is oversubscribed. Bandwidth overestimation occurs 
when the link is undersubscribed or perfectly subscribed. In 
general, when the number of competing clients is n, the 
bandwidth overestimation ranges from one to n times the fair- 
share bandwidth. 

Although the preceding simple examples assume idealized 
TCP behavior which abstracts away the complexity of TCP 
congestion control dynamics, it is easy to verify that similar 
behavior occurs with real TCP connections. To see this, 
we conducted a simple test bed experiment as follows. We 
implemented a "thin client" to mimic an HAS client in the 
steady-state mode. Each thin client repeatedly downloads a 
segment every 2 seconds. We run 100 instances of the thin 
client sharing a bottleneck link of 100 Mbps, each with a 
starting time randomly selected from a uniform distribution 
between and 2 seconds. Figure |5] plots the measured average 
TCP throughput as a function of the link subscription rate. 
We observe that when the link subscription is below 100%, 
the measured throughput is about 3x the fair-share bandwidth 
of ~1 Mbps. When the link subscription is above 100%, the 
measured throughput successfully predicts the fair-share band- 
width quite accurately. We refer to this sudden transition from 
overestimation to fairly accurate estimation of the bandwidth 
share at 100% subscription as the bandwidth cliff effect. 

We summarize our findings as follows: 

• Link oversubscription converges to fully overlapped 
bandwidth sharing and accurate bandwidth estimation. 

• Link undersubscription converges to a bandwidth sharing 
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Fig. 5. Bandwidth chff effect: measured TCP throughput vs. link subscription 
rate for 100 thin clients sharing a 100-Mbps link. Each thin client repeatedly 
downloads a segment every r = 2 seconds. 

pattern determined by the download start times and 
bandwidth overestimation. 
• In perfect link subscription, there exist unlimited band- 
width sharing modes, leading to bandwidth overestima- 
tion. 

B. Video Bitrate Oscillation 

With an understanding of the bandwidth cliff effect, we 
are now in a good position to explain the bitrate oscillation 
observed in Figure [T] 

Figure |6] illustrates this process. When the client buffer 
reaches the maximum level Smax, by (|6]l, off-intervals start 
to emerge. The link becomes undersubscribed, leading to 
bandwidth overestimation (a). This triggers the upshift of 
requested video bitrate (b). As the available bandwidth cannot 
keep up with the video bitrate, the buffer falls below Bmax. By 
(|6]l, the client falls back to the buffer growing mode and the 
off-intervals disappear, in which case the link again becomes 
oversubscribed and the measured throughput starts to converge 
to the fair-share bandwidth (c). Lastly, due to the quantization 
effect, the requested video bitrate falls below the fair-share 
bandwidth (d), and the client buffer starts growing again, 
completing one oscillation cycle. 
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Fig. 6. Illustration of vicious cycle of video bitrate oscillation. This plot is 
obtained with 36 Smooth clients shaiing a 100-Mbps Unk. For experimental 
setup, refer to i|VII-B| 

C. Fundamental Limitation 

The bandwidth overestimation phenomenon reveals a more 
general and fundamental limitation of the class of conven- 
tional reactive bandwidth estimation approaches discussed so 
far As video bitrates are chosen solely based on measured 
TCP throughput from past segment downloads during the 
on-intervals, such decisions completely ignore the network 
conditions during the off-intervals. This leads to an ambiguity 
of client knowledge of available network bandwidth during the 
off-intervals, which, in turn, hampers the adaptation process. 

To illustrate this point, consider two alternative scenarios as 
depicted in Figures|4](f) and (a). In (f), the client downloading 
the blue (darker-shaded) video segments occupies the link 
alone; in (a), it shares the same link with a competing client 
downloading the green (lighter-shaded) video segments. Note 
that the on/off-intervals for all the blue (darker-shaded) video 
segments follow exactly the same pattern in both scenar- 
ios. Consequently, the client observes exactly the same TCP 
throughput measurement over time. If the client would obtain 
a complete picture of the network, it would know to upshift 
its video bitrate in if) but retain its current bitrate in (a). 
In practice, however, an individual client cannot distinguish 
between these two scenarios, hence, is bound to the same 
behavior in both. 

Note that as long as the off-intervals persist, such ambiguity 
in client knowledge is inherent to the bandwidth measure- 
ment step in a network with competing streams. It cannot 
be resolved or remedied by improved filtering, quantization, 
or scheduling steps performed later in the client adaptation 
algorithm. Moreover, the bandwidth cliff effect, as discussed 
in Section IV-AI suggests that the bandwidth overestimation 
problem does not improve with more clients, and that it can 
introduce large errors even with slight link undersubscription. 

Instead, the client needs to take a more proactive approach 
in adapting the video bitrate — whenever it is known that 
the client knowledge is impaired, it must avoid using such 
knowledge in bandwidth estimation. A way to distinguish the 
case when the knowledge is impaired from when it is not, is to 
probe the network subscription by small increment of its data 
sending rate. We describe one algorithm that follows such an 
alternative approach in the next section. 



VI. Probe-and-Adapt Approach 

In this section, we introduce our proposed probe-and-adapt 
approach to directly address the root cause of the conventional 
algorithms' problems. We begin the discussion by laying 
out the design goals that a rate adaptation algorithm aims 
to achieve. We then describe the PANDA algorithm as an 
embodiment of the probe-and-adapt approach, and provide its 
functional verification using experimental traces. 

A. Design Goals 

Designing an HAS rate adaptation algorithm involves trade- 
offs among a number of competing goals. It is not legitimate 
to optimize one goal (e.g., stability) without considering its 
tradeoff factors. From an end-user's perspective, an HAS rate 
adaptation algorithm should be designed to meet these criteria: 

> Avoiding buffer underrun. Once the playout starts, buffer 
underrun (i.e., complete depletion of buffer) leads to a 
playout stall. Empirical study lH) has shown that buffer 
underrun may have the most severe impact on a user's 
viewing experience. To avoid it, some minimal buffer 
level must be maintained at all time^ and the adap- 
tation algorithm must be highly responsive to network 
bandwidth drops. 

• High quality smoothness. In the simplest setting without 
considering visual perceptual models, high video quality 
smoothness translates into avoiding both frequent and 
significant video bitrate shifts among available video 
bitrate levels lfT3l, ifTSl. 

> High average quality. High average video quality dictates 
that a client should fetch high-bitrate segments as much as 
possible. Given a fixed network bandwidth, this translates 
into high network utilization. 

> Fairness. In the simplest setting, fairness translates 
into equal network bandwidth sharing among competing 
clients. 

Note that this list above is non-exhaustive. Other criteria, 
such as low playout startup latency, are also important factors 
impacting user's viewing experience. 

B. PANDA Algorithm 

In this section, we discuss the PANDA algorithm. Compared 
to the reactive bandwidth estimation used by a conventional 
rate adaptation algorithm, PANDA uses a more proactive 
probing mechanism. By probing, PANDA determines a target 
average data rate x. This average data rate is subsequently 
used to determine the video bitrate r to be fetched, and the 
interval T until the next segment download request. 

The PANDA algorithm is described in Algorithm |2] and 
a block diagram interpretation of the algorithm is shown in 

^Note that, however, the buffer level must also have an upper bound, for a 
few different reasons. In live streaming, the end-to-end latency from the real- 
time event to the event being displayed on user's screen must be reasonably 
short. In video-on-demand, the maximum buffered video must be limited to 
avoid wasted network usage in case of an early termination of playback and 
to limit memory usage. 



Algorithm 2 PANDA 



At the beginning of each downloading step n: 
1) Estimate the bandwidth share x[n] by 



x[n] — x[n — 1] 



K ■ {w — max{0, x[n — 1] — x[n — 1])), (7) 



T[n - 1] 

2) Smooth out x[n] to produce filtered version y[n] by 

y[n] = S{{x[m] : m < n}). (8) 

3) Quantize y[n] to the discrete video bitrate r[n] dlZ by 

r[n] = Q{y[n];...). (9) 

4) Schedule the next download request via 

T[n] = -Lf— + 13 ■ {B[n -I]- (10) 



Figure |7] Compared to the conventional algorithm in Algo- 
rithm [T] we only make modifications in the estimating and 
scheduling steps - we replace (O with dTji for estimating the 
bandwidth share, and ^ with (fTol l for scheduling the next 
download request. We now focus on elaborating each of these 
two modifications. 

In the estimating step, (|7]l is designed to directly address 
the root cause that leads to the video bitrate oscillation 
phenomenon. Based on the insights obtained from i jV-AI when 
the link becomes undersubscribed, the direct TCP throughput 
estimate x becomes inaccurate in predicting the fair-share 
bandwidth, and thus should be avoided. Instead, the client 
continuously increments the target average data rate £ by k-w 
per unit time as a probe of the available capacity. Here k is the 
probing convergence rate and w is the additive increase rate. 
The algorithm keeps on monitoring the TCP throughput x, and 
compares it against the target average data rate x. If x > x, 
X would not be informative, since in this case the link may 
still be undersubscribed and x may overestimate the fair-share 
bandwidth. Thus, its impact is suppressed by the max(0, •) 
function. But if a; < i, then TCP throughput cannot keep up 
with the target average data rate indicates that congestion has 
occurred. This is when the target data rate x should back off. 
The reduction imposed on x is made proportional to x — x. 
Intuitively, the lower the measured TCP throughput x, the 
more reduction that needs to be imposed on x. This design 
makes our rate adaptation algorithm very agile to bandwidth 
changes. 

panda's probing mechanism shares similarities with 
TCP's congestion control fTPl, and has an additive-increase- 
multiplicative-decrease (AIMD) interpretation: k ■ w is the 
additive increase term, and — K-max(0, i[n— 1] — 1]) can 
be interpreted as the multiplicative decrease term. The main 
difference is that in TCP, congestion is indicated by packet 
losses (TCP Reno) or increased round-trip time (delay-based 
TCP), whereas in (|7]l, congestion is indicated by the reduction 
of measured TCP throughput. This AIMD property ensures 
that PANDA is able to efficiently utilize the network band- 
width, and in the presence of multiple clients, the bandwidth 



for each client eventually converges to fair-share status^. 

In the scheduling step, ( fTOl l aims to determine the target 
inter-request time T[n]. By right, T[n] should be selected such 
that the smoothed target average data rate y[n] is equal to 
^id-I. But additionally, the selection of T[n] should also drive 
the buffer B [n\ towards a minimum reference level Smin > 0, 
so the second term is added to the right hand side of (fTOl i. 
where /? > controls the convergence rate. 

One distinctive feature of the PANDA algorithm is its 
hybrid closed-loop/open-loop design. Refer to Figure |7] In 
this system, d?) forms a closed loop by itself that determines 
the target average data rate x. (fTOl i forms a closed loop by 
itself that determines the target inter-request time T. Overall, 
the estimating, smoothing, quantizing and scheduling steps 
together form an open loop. The main motivation behind 
this design is to reduce the bitrate shifts associated with 
quantization. Since quantization is excluded from the closed 
loop of X, it allows x to settle in a steady state. Since r[n] is 
a deterministic function of x[n], it can also settle in a steady 
state. 

In the Appendix, we present an equilibrium and stability 
analysis of PANDA. We summarize the main results as fol- 
lows. Our equilibrium analysis shows that at steady state, the 
system variables settle at 



Xo — Xo +w 

— Q {^O ; • ■ ■ ) 

Bo = + Smin, 



(11) 



(12) 



where the subscript o denotes value of variables at equilibrium. 
Our stability analysis shows that for the system to converge 
towards the steady state, it is necessary to have: 

2 



K < 

T 

w < A, 



(13) 
(14) 



where A is a parameter associated with the quantizer Q{-), 
referred to as the quantization margin, i.e., the selected discrete 
rate r must satisfy 



r[n\ < y[n\ 



(15) 



C. Functional Verification 

We verify the behavior of PANDA using experimental 
traces. For detailed experiment setup (including the selection 
of function S{-) and Q(-)), refer to WII-BI 

First, we evaluate how a single PANDA client adjusts its 
video bitrate as the the available bandwidth varies over time. 
In Figure |8] we plot the TCP throughput x, the target average 
data rate x, the fetched video bitrate r and the client buffer 
B for a duration of 500 seconds, where the bandwidth drops 
from 5 to 2 Mbps at 200 seconds, and rises back to 5 Mbps at 
300 seconds. Initially, the target average data rate x ramps up 

^Assuming the underlying TCP is fair (e.g., equal RTTs). 
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Fig. 8. A PANDA client adapts its video bitrate under a bandwidth-varying 
link. The bandwidth is initially at 5 Mbps, drops to 2 Mbps at 200 seconds 
and rises back to 5 Mbps at 300 seconds. 

gradually over time; the fetched video bitrate r also ramps up 
correspondingly. After the initial ramp-up stage, x settles in a 
steady state. It can be observed that at steady state, the differ- 
ence between x and x is about 0.3 Mbps, equal to w, which 
is consistent with (fTTI) . Similarly, the buffer B also settles in 
a steady state, and after plugging in all the parameters, one 
can verify that the steady state of buffer (fTzt also holds. At 
200 seconds, when the bandwidth suddenly drops, the fetched 
video bitrate quickly drops to the desirable level. With this 
quick response, the buffer hardly drops. This property makes 
PANDA favorable for live streaming applications. When the 
bandwidth rises back to 5 Mbps at 300 seconds, the fetched 
video bitrate gradually ramps up to the original level. 

Note that, in practical implementation, we can further add 
startup logic to improve PANDA' s rate ramp-up speed at the 
initial stage. Since off-intervals would not need to appear 
before the buffer reaches the minimum reference level, a con- 
ventional rate adaptation algorithm based on TCP throughput 
measurement would suffice. 

The more intriguing question is whether PANDA could 
effectively stop the bitrate oscillation observed in the Smooth 
players. We conduct an experiment with the same setup as the 
experiment shown in Figure [T] except that the PANDA player 
and the Smooth player use slightly different video bitrate 
levels (due to different packaging methods). The resulting 
fetched bitrates in aggregate and for each client are shown 
in Figure |9] From the plot of the aggregate fetched bitrate, 
except for the initial fluctuation, the aggregate bitrate closely 
tracks the available bandwidth of 100 Mbps. Zooming in to 
the individual streams' fetched bitrates, the fetched bitrates 
are confined within two adjacent bitrate levels and the number 
of shifts is much smaller than the Smooth client's case. This 
affirms that PANDA is able to achieve better stability than 
the Smooth's rate adaptation algorithm. In we perform 

a comprehensive performance evaluation on each adaptation 
algorithm. 

To help the reader develop a better intuition on why PANDA 
performs better than a conventional algorithm, in Figure [TO] we 
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Fig. 9. 36 PANDA clients compete at a 100-Mbps link in steady state. 

plot the trace of the measured TCP throughput and the target 
average data rate for the same experiment as in Figure |9] Note 
that the fair-share bandwidth for each client is about 2.8 Mbps. 
From the plot, the TCP throughput not only grossly overesti- 
mates the fair-share bandwidth, it also has a large variation. 
If used directly, this degree of noisiness gives the subsequent 
operations a very hard job to extract useful information. For 
example, one may apply strong filtering to smooth out the 
bandwidth measurement, but this would seriously affect the 
responsiveness of the client. When the network bandwidth 
suddenly drops, the client would not be able to respond quickly 
enough to reduce its video bitrate, leading to catastrophic 
buffer underrun. Moreover, the bias is both large and difficult 
to predict, making any correction to the mean problematic. In 
comparison, although also biased, the target average data rate 
estimated by the probing mechanism is much less noisy than 
the TCP throughput. One can easily correct the bias (via (ITSt 
and quantization) and select the right video bitrate without 
sacrificing responsiveness. 

In Figure (TT] we verify the stability criteria (|T3l and (IT4t 
of PANDA. With r = 2, the system is stable if k < 1. This 
is demonstrated by Figure [TT] (a), where we show the traces 
of the target average rate x for two k values 0.9 and 1.1. In 
Figure [TT] (b), we show that when A = 0, the buffer cannot 
converge towards the reference level of 30 seconds. 

VII. Performance Evaluation 

In this section, we conduct a set of test bed experiments 
to evaluate the performance of PANDA against other rate 
adaptation algorithms. 
A. Evaluation Metrics 

In WI-AI we discussed four criteria that are most important 
for a user's watching experience - i) ability to avoid buffer 
underruns, ii) quality smoothness, iii) average quality, and iv) 
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Fig. 10. The traces of the TCP thi'oughput and the target average data rate 
of 36 PANDA chents compete at a 100-Mbps link in steady state. The traces 
of the first five clients are plotted. 

fairness. In this paper, we use buffer undershoot as the metric 

for Criterion i), described as follows. 

« Buffer undershoot: We measure how much the buffer 
goes down after a bandwidth drop as a indicator of an 
algorithm's ability to avoid buffer undermns. The less the 
buffer undershoot, the less likely the buffer will underrun. 
Let Bo be a reference buffer level (30 seconds for all 
players in this paper), and Bi t the buffer level for player 
i at time t. The buffer undershoot for player i at time t 
is defined as ™^^^"'p° The buffer undershoot for 



Bo 

player i within a time interval T (right after a bandwidth 
drop), is defined as the 90th-percentile value of the 
distribution of buffer undershoot samples collected during 

r. 

We inherit the metrics defined in fT3\ - instability, inefficiency 
and unfairness, as the metrics for Criteria ii), iii) and iv), re- 
spectively. We only make a slight modification to the definition 
of inefficiency. Let t be the video bitrate fetched by player 
i at time t. 

• Instability: The instability for player i at time t is 



d = Q 



o{d) 



where w{d) 



d is 



weight function that puts more weight on more recent 
samples, k is selected as 20 seconds. 

• Inefficiency: Let C be the available bandwidth. llT3l 

defines inefficiency as — — for player i at time t. 
But sometimes the sum of fetched bitrate '''i,t can be 
greater than C. To avoid unnecessary penalty in this case, 

, . . . maxfo.C — y],- r; f ) 

we revise the metficiency metric to — ^ — tor 

player i at time t. 

• Unfairness: Let JainFairt be the Jain fairness index 
calculated on the rates ri^t at time t over all players. The 
unfairness at t is defined as \/l — JainFairt- 

B. Experimental Setup 

HAS Player Configuration: The benchmark players that we 
use to compare against PANDA are: 

• Microsoft Smooth player \5\, a commercially available 
proprietary player The Smooth players are of version 
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Fig. 11. Experimental verification of PANDA's stability criteria. In (a), one 
PANDA client streams over a link of 5 Mbps. In (b), 10 PANDA clients 
compete over a 10 Mbps link. 

LO.837.34 using Silverlight runtime version 4.0.50826. 
To our best knowledge, the Smooth player as well as the 
Apple HLS and the Adobe HDS players all use the same 
TCP throughput measurement mechanism, so we picked 
the Smooth player as a representative. 

• FESTIVE player, which we implemented based on the 
details specified in ifTSl . The FESTIVE algorithm is the 
first known client-side rate adaptation algorithm designed 
to specifically address the multi-client scenario. 

• A player implementing the conventional algorithm (Al- 
gorithm [U, which differs from PANDA only in the 
estimating and scheduling steps. 

For fairness, we ensure that PANDA and the conventional 
player use the same smoothing and quantizing functions. For 
smoothing, we implemented a EWMA smoother of the form: 

'^^rTnlT^' " ~" ■ ^y^^ " ^] ~ ^t""])' ^^^""^ a > is the 
convergence rate of y[n] towards x[n]. For quantization, we 

implemented a dead-zone quantizer r[n\ = Q(jj[n\,r[n — 1]), 

defined as follows: Let the upshift threshold be defined as 

r„p :— maxrgTjr subject to r < y[n] — A„p, and the 

downshift threshold as r^own '■= max^eKr subject to 

< y[n] — /^down, where A^jp and A^oum are the upshift and 

downshift safety margin respectively, with A„p > lS.down > 0. 

The dead-zone quantizer updates r[n] as 



r[n - 1] < Tup, 

Tup <r[n-l] < rdo 

otherwise. 



(16) 



The "dead zone" [r^p, rdown] created by setting A„p > Adown 
mitigates frequent bitrate hopping between two adjacent levels, 
thus stabilizing the video quality (i.e. hysteresis control). For 
the conventional player, set A„p — £-y and Adown ~ 0, where 
< e < 1 is the multiplicative safety margin. For PANDA, 
due to (fT4l l and (fTSl l. set A„p = w + e ■ y and Adown = w 0- 

Table lists the default parameters used by each player, as 
well as their varying values. For fairness, all players attempt 
to maintain a steady-state buffer of 30 seconds. For PANDA, 
^min is selected to be 26 seconds such that the resulting 
steady-state buffer is 30 seconds (by (fT2]l). 

Server Configuration: The HTTP server runs Apache on 
Red Hat 6.2 (kernel version 2.6.32-220). The Smooth player 

^Note that this will not give PANDA any unfair advantage. 
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CK 
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0.01,0.04,0.07,0.1,0.15,0.2 
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0.15 








30 




FESTIVE 


Window 


20 
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targetbuf 


30 





TABLE II 
Parameters used in experiments 
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Fig. 12. The network topology contigured in the test bed. Local indicates 
that the bitrate is effectively unbounded and the link delay is ms. 



interacts with an Microsoft IIS server by default, but we also 
perform experiments of Smooth player interacting with an 
Apache server on Ubuntu 10.04 (kernel version 2.6.32.21). 

Network Configuration: As service provider deployment 
over a managed network is our primary case of interest, 
our experiments are configured to highly match the imporant 
scenario where a number of HAS flows compete for bandwidth 
within a DOCSIS bonding group. The test bed is configured 
as in Figure [12] The queueing policy used at the aggregation 
router-home router bottleneck link is the following. For a link 
bandwidth of 10 Mbps or below, we use random early de- 
tection (RED) with {min_thr,max_thr,p) ~ (30,90,0.25); 
if the link bandwidth is 100 Mbps, we use RED with 
{min_thr, max_thr,p) = (300, 900, 1). The video content is 
chopped into segments of r = 2 seconds, pre-encoded with 
L = 10 bitrates: 459, 693, 937, 1270, 1745, 2536, 3758, 5379, 
7861 and 11321 Kbps. For the Smooth player, the data rates 
after packaging are slightly different. 

C. Performance Tradeoffs 

It would not be legitimate to discuss a single metric without 
minding its impact on other metrics. In this section, we 
examine the performance tradeoffs among the four metrics 
of interest. We designed an experimental process under which 
we can measure all four metrics in a single run. For each run, 
five players (of the same type) compete at a bottleneck link. 
The link bandwidth stays at 10 Mbps from seconds to 400 
seconds, drops to 2.5 Mbps at 400 seconds and stays there 
until 500 seconds. We record the instability, inefficiency and 
unfairness averaged over to 400 seconds over all players, and 
the buffer undershoot over 400 to 500 seconds averaged over 
all players. Figure [13] shows the tradeoff between stability and 
each of the other criteria - buffer undershoot, inefficiency and 
unfairness - for each of the types of player. Each data point 
is obtained via averaging over 10 runs, and each data point 



represents a different value for one of the parameters of the 
corresponding algorithm, as indicated in the Values column of 
Table In] 

For the PANDA player, the three parameters that affect 
instability the most are: the probing convergence rate k, the 
smoothing convergence rate a and the safety margin e. Figure 
[T3] (a) shows that as we vary these parameters, the tradeoff 
curves mostly stay flat (except for at extreme values of these 
parameters), implying that the PANDA player maintains good 
responsiveness as the stability is improved. A few factors 
contribute to this advantage of PANDA: First, as the bandwidth 
estimation by probing is quite accurate, one does not need 
to apply strong smoothing. Second, since after a bandwidth 
drop, the video bitrate reduction is made proportional to the 
TCP throughput reduction, PANDA is very agile to bandwidth 
drops. On the other hand, for both the FESTIVE and the 
conventional players, the buffer undershoot significantly in- 
creases as the scheme becomes more stable. Overall, PANDA 
has the best tradeoff between stability and responsiveness to 
bandwidth drop, outperforming the second best conventional 
player by more than 75% reduction in instability at the same 
buffer undershoot level. It is worth noting that the conventional 
player uses exactly the same smoothing and quantization 
steps as PANDA, which implies that the gain achieved by 
PANDA is purely due to the improvement in the estimating and 
scheduling steps. FESTIVE has the largest buffer undershoot. 
We believe this is because the design of FESTIVE has mainly 
concentrated on stability, efficiency and fairness, but ignored 
responsiveness to bandwidth drops. As we do not have access 
to the Smooth player's buffer, we do not have its buffer 
undershoot measure in Figure [13] (a). 

Figure [13] (b) shows that PANDA has the lowest inefficiency 
over all as we vary its instability. The probing mechanism 
ensures that the bandwidth is most efficiently utilized. As the 
instability increases, the inefficiency also increases moderately. 
This makes sense intuitively, as when the bitrate fluctuates, 
the average fetched bitrate also decreases. The efficiency 
of the conventional algorithm underperforms PANDA, but 
outperforms FESTIVE. Lastly, the Smooth player has the 
highest inefficiency. 

Lastly, Figure [T3] (c) shows that in terms of fairness, 
FESTIVE achieves the best performance. This may be due to 
the randomized scheduling strategy of FESTIVE. PANDA and 
the conventional players have similar fairness; both of them 
outperform the Smooth player 

D. Increasing Number of Players 

In this section, we focus on the question of how the number 
of players affects instability, inefficiency and unfairness at 
steady state. Two scenarios are of interest: i) we increase 
the number of players while fixing the link bandwidth at 10 
Mbps, and ii) we increase the number of players while varying 
the bandwidth such that the bandwidth/player ratio is fixed 
at 1 Mbps/player Figure [14] and Figure [15] report results for 
these two cases, respectively. Each data point is obtained by 
averaging over 10 runs. 




Refer to Figure [14] (a). In the single-player case, all four 
schemes are able to maintain their fetched video bitrate at a 
constant level, resulting in zero instability. As the number of 
players increases, the instability of the conventional player and 
the Smooth player both increase quickly in a highly consistent 
way. We speculate that they have very similar underlying 
structure. The FESTIVE player is able to maintain its stability 
at a lower level, due to the strong smoothing effect (smoothing 
window at 20 samples by default), but the instability still 
grows with the number of players, likely due to the bandwidth 
overestimation effect. The PANDA player exhibits a rather 
different behavior: at two players it has the highest instability, 
then the instability starts to drop as the number of players 
increases. Investigating into the experimental traces reveals 
that this is related to the specific bitrate levels selected. More 
importantly, via probing, the PANDA player is immune to the 
symptoms of the bandwidth overestimation, thus it is able 
to maintain its stability as the number of clients increases. 
The case of varying bandwidth in Figure [15] (a) exhibits 
behavior fairly consistent with Figure [14] (a), with PANDA 
and FESTIVE exhibiting much less instability compared to 
the Smooth and the conventional players. 

Figure [14] (b) and Figure [15] (b) for the inefficiency metric 
both show that PANDA consistently has the best performance 
as the number of players grow. The conventional player and 
FESTIVE have similar performance, both outperforming the 
Smooth player by a great margin. We speculate that the 
Smooth player has some large bitrate safety margin by design, 
with the purpose of giving cross traffic more breathing room. 

Lastly, let us look at fairness. Refer to Figure [14] (a). We 
have found that when the overall bandwidth is fixed, the 
unfairness measure has high dependence on the specific bitrate 
levels chosen, especially when the number of players is small. 
For example, at two players, when the fair-share bandwidth 
is 5 Mbps, the two PANDA players end up in steady state 
with 5.3 Mbps and 3.7 Mbps, resulting in a high unfairness 
score. At three players, when the fair-share bandwidth is 3.3 
Mbps, the three PANDA players each end up with 3.7, 3.7 
and 2.5 Mbps for a long period of time, resulting in a lower 
unfairness score. FESTIVE exhibits lowest unfairness overall, 
which is consistent with the results obtained in Figure [13] (c). 
In the varying-bandwidth case in Figure[T5](c), The unfairness 
ranking is fairly consistent as the number of players grow: 
FESTIVE, PANDA, the conventional, and Smooth. 



E. Competing Mixed Players 

One important question to ask is how PANDA will behave 
in the presence of different type of players? If it behaves too 
conservatively and cannot grab enough bandwidth, then the 
deployment of PANDA will not be successful. To answer this 
question, we take the four types of players of interest and have 
them compete on a 10-Mbps link. For the Smooth player, we 
test it with both a Microsoft IIS server running on Windows 
7, and an Apache HTTP server running on Ubuntu 10.04. A 
single trace of the fetched bitrates for 500 seconds is shown 
in Figure [16] The plot shows that the Smooth player's ability 
to grab the bandwidth highly depends on the server it streams 
from. Using the IIS server, which runs on Windows 7 with an 
aggressive TCP, it is able to fetch video bitrates over 3 Mbps. 
With the Apache HTTP server, which uses Ubuntu 10.04's 
conservative TCP, the fetched bitrates are about 1 Mbps. The 
conventional, PANDA and FESTIVE players all run on the 
same TCP (Red Hat 6), so their differences are due to their 
adaptation algorithms. Due to bandwidth overestimation, the 
conventional player aggressively fetches high bitrates, but the 
fetched bitrates fluctuate. Both PANDA and FESTIVE are able 
to maintain a stable fetched bitrate at about the fair-share level 
of 2 Mbps. 

F. Summary of Performance Results 

• The PANDA player has the best stability-responsiveness 
tradeoff, outperforming the second best conventional 
player by 75% reduction in instability. PANDA also has 
the best bandwidth utilization. 

• The FESTIVE player has been tuned to yield high sta- 
bility, high efficiency and good fairness. However, it un- 
derperforms other players in responsiveness to bandwidth 
drops. 

• The conventional player yields good efficiency, but lacks 
in stability, responsiveness to bandwidth drops and fair- 
ness. 

• The Smooth player underperforms in efficiency, stability 
and fairness. When competing against other players, 
its ability to grab bandwidth is a consequence of the 
aggressiveness of the underlying TCP stack. 

VIII. Conclusions 

This paper identifies an emerging issue for HTTP adaptive 
streaming, which is expected to become the predominant form 
of the Internet traffic, and lays out a solution direction that can 
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effectively address this issue. Our main contributions in this 
paper can be summarized as follows: 

• We have identified the bandwidth cliff effect as the root 
cause of the bitrate oscillation phenomenon and revealed 
the fundamental limitation of the conventional reactive 
measurement based rate adaptation algorithms. 

• We have envisioned a general probe-and-adapt principle 
to directly address the root cause of the problems, and 
designed and implemented PANDA, a client-based rate 
adaptation algorithm, as an embodiment of this principle. 

• We have proposed a generic four-step model for an HAS 
rate adaptation algorithm, based on which we have fairly 
compared the proposed approach with the conventional 
approach. 

The probe-and-adapt approach and our PANDA realization 
thereof achieve significant improvements in stability of HAS 
systems at no cost in responsiveness. Given this framework, 
we plan to explore further improvements in our future work. 
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Analysis of T and B 

Assume no smoothing x = y. During transient states, when 
T = T > T, update of T pushes the playout buffer size in the 
right direction: T < ^-j^ leads to a steady growth in buffer 

size when B < Bmhi- At steady state, fo = T = fo>fo.lt 
can be derived from (fTOt that: 



Bn — Br, 



1 



To 



T 



where Bo is playout buffer at equilibrium. 



Appendix 

We perform an equilibrium and stability analysis of 
PANDA. For simplicity, we only analyze the single-client case 
where the system has an equilibrium point. 



Analysis of x 

Assume the measured TCP download throughput x is equal 
to the link capacity C. Consequently, (|7]i can be re-written in 
two scenarios (refer to Figure (|3)) as: 



a;[n] — — 1] j k • u;, if x < C, 

T[n — 1] yK ■ w — K ■ {x[n — 1] — C), otherwise. 

(17) 

At equilibrium, setting ([TtI i to zero leads Xo w — Xo — C, 
hence, Xo — C + w>Xo = C. 

Considering the simplifying assumptions of y = x (no 
smoothing) and a quantizer with a margin A such that 
r ^ y — A, we need r,, = Xo — A < C at equilibrium. 
Therefore, the quantization margin of the quantizer needs to 
satisfy 

A > Xo ^ C = w, 

so that the system stays on the multiplicative-decrease side of 
the equation at steady state. 

Note that close to equilibrium, the intervals between consec- 
utive segment downloads match the segment playout duration 
r[77,— 1] = r, therefore, calculation of the estimated bandwidth 
X follows the simple form of a difference equation: 



x\n 



11+6. 



The two constants are: a ~ 1 ~ k ■ t and h = k ■ {C + w) ■ t. 
The sequence converges if and only if |a| < 1. Hence, we 
need: — 1<1 — K-r<l, leading to the stability criterion: 



2 

< fc < -. 

T 



